Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000076_owner-urn-ietf _Tue Oct 22 18:31:51 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA16892 for urn-ietf-out; Tue, 22 Oct 1996 18:31:51 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA16877 for <[e-mail]>; Tue, 22 Oct 1996 18:31:46 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA11419  (mail destined for [e-mail]); Tue, 22 Oct 96 18:31:43 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA14249; Tue, 22 Oct 1996 16:31:34 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Oct 1996 16:39:10 -0600
To: Patrik Faltstrom <[e-mail]>, Larry Masinter <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Patrik Faltstrom (at least at 11:31 PM 10/22/96 +0200)
>On Tue, 22 Oct 1996, Larry Masinter wrote:

>> For example, the NAPTR resolution scheme depends on regular expression
>> patterns which will not work well if all of the different syntactic
>> variations of URNs might be allowed.

>So far in the
>NAPTR proposal, _no_ regular expression is operating on the
>opaque string, even though that is possible, and interesting,
>in some namespaces.

Sorry Patrik, but the CID example and HTTP example both
extract a domain name from the opaque (NSS) portion of the URN.
Larry is correct that allowing lots of legal syntactic variants
can cause problems for the NAPTR scheme.

(Although the particular example of ISBNs would almost certainly
not be one of the cases where a problem arises. But I digress).

However, we are not talking about the same problems here.
One problem is that of lexical equivalance - the mappings all clients
need to know in order to answer the question "is it safe to regard
URN1 and URN2 as identifying the same resource". The second problem
is that of "is this URN a legal name from namespace foo"? The
second problem can't be solved in general by clients without
adopting extraordinary means, means that we have not in the past been
willing to require and I have no desire to start requiring now.


I agree that we need to define the legal form for names from namespaces
like ISBN. I think that will happen by someone preparing drafts with
titles like "The ISBN: Namespace" and we run them through review. Those
documents will have to define what are legal encodings of names, and
I think there should be as little variation as possible. But since
a client can't answer the question of "is this name legal" all it can
do is start following a resolution procedure. Resolution procedures
that try to support namespace foo MUST be able to handle the legal
encodings of names from that namespace. If that procedure wants
to attempt some sophisticated error recovery, to handle names that
have a different encoding, I say let it. If the sense of the list
is to prohibit sophisticated error recovery, well, then any documents
I edit will say that it is prohibited behavior.

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"